fix(auth): convert stolen-lock AbortError when acquireTimeout is 0 - #2616
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan includes up to 8 reviews per rolling hour; 7 remain after this review. 📝 WalkthroughSummary by CodeRabbit
Walkthrough
Assessment against linked issues
Possibly related issues
Possibly related PRs
Merge Risk: ⚪ Minimal · up to This localized change converts a stolen-lock failure into the existing typed error path and adds regression coverage for the zero-timeout case. No actionable merge-blocking risk remains beyond normal checks and review. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Coverage is 73.754% — mmustafasenoglu:fix/stolen-lock-abort-error-acquire-timeout-zero into supabase:master. No base build found for |
This PR updates `@supabase/supabase-js` to v2.112.4. **Source**: supabase-js-stable-release --- ## Release Notes ## v2.112.4 ## 2.112.4 (2026-08-24) ### 🩹 Fixes - **auth:** convert stolen-lock AbortError when acquireTimeout is 0 ([#2616](supabase/supabase-js#2616)) - **auth:** warn on deprecated lock option and prevent unhandled refresh rejection ([#2627](supabase/supabase-js#2627)) - **postgrest:** move override fixtures out of generated types, repair codegen ([#2605](supabase/supabase-js#2605)) - **realtime:** respect custom logger for send() REST fallback warning ([#2612](supabase/supabase-js#2612)) ### ❤️ Thank You - Katerina Skroumpelou @mandarini - mmustafasenoglu @mmustafasenoglu This PR was created automatically. Co-authored-by: supabase-workflow-trigger[bot] <266661614+supabase-workflow-trigger[bot]@users.noreply.github.com>
Fixes #2620
_autoRefreshTokenTickcallsnavigatorLockwithacquireTimeout = 0, which requests the lock with{ ifAvailable: true }and no abort signal. When another context steals the lock, the browser rejects with a rawAbortError. The catch block only convertedAbortErrorwhenacquireTimeout > 0, so the raw error escaped as an unhandled rejection.Dropped the
acquireTimeout > 0guard and now branch onabortController.signal.abortedalone. With no timer armed the signal is never aborted, so a stolen lock routes to the existing "stolen from us" branch and is converted to the typedNavigatorLockAcquireTimeoutError, which_autoRefreshTokenTickalready catches.Changes:
packages/core/auth-js/src/lib/locks.ts: removed theacquireTimeout > 0condition from the AbortError conversion guardpackages/core/auth-js/test/lib/locks.test.ts: added a test covering a stolen lock withacquireTimeout = 0(no steal-back, typed error thrown)